iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 9
0

啟稟軍師,東風來了

Imgur

等了好久,終於等到東風了,我們可以開始慢慢的推導了。

如何處理 Build fail

如果是 Build fail ,通常就是少上傳東西,導致建構失敗, CI 會在有人受害前就幫我們發現這個問題。這個通常是 Coding 的習慣還沒養成。

此時你可以上前告訴他,剛剛上傳的東西好像有點問題,跟他一起找一下問題,並宣揚一下這是 CI 幫助我們發現的,讓大家知道原來你搞了一台 CI 還是有一點點作用。

如何處理 Test fail

如果是 Test fail ,請你拿著測試情境去跟夥伴討論一下,跟他說他剛剛修改的東西好像在這樣的測試情境下會有問題,並且有耐心的跟他一起解決問題。

最好順便多加幾個測試情境。同時宣揚一下 CI 會在我們 Commit code 時幫我們跑測試,會幫我們確保我們的程式碼執行是正確的。

當然,正確使用單元測試的時機,是修改程式的時候就應該要馬上跑單元測試。不過對還沒養成跑測試習慣的人來說, CI 幫我們在交付程式碼時,給了我們一層保護。

讓大家感受到自動化測試的好處

當這樣的情況多發生幾次後,團隊成員就會感受到 CI 和自動化測試所帶來的好處,而且你們交付出去的東西被發現 Bug 的次數就會變少。

想必此時已經有不少的團隊成員對寫測試有興趣了,接下來就把你之前怎麼慢慢學習的,跟他們再一起走一次吧。我相信會比一開始就強迫大家寫來的順利多了。

接下來所面對的問題

這時你可能會遇到另一個問題,不是每個人都會想用另外的 20 小時來學習的,就算他們用了那 20 小時來學習寫測試,也會面臨另一個問題,為什麼我要花自己的時間在幫工作上的程式寫測試。最後大家會想把測試台面化,也就是用上班時間光明正大的寫測試。

然而測試台面化第一個所要面臨的問題就是 PO/PM,他們會覺得你們所開發的東西變少或變慢了。

今天請你先想一想面對這個問題我們該怎麼辦,明天我們再來討問一下。


上一篇
Day 8 我該強迫其他人一起寫測試嗎?
下一篇
Day 10 寫測試會降低我的生產力怎麼辦?
系列文
那些敏捷開發裡的小事30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言